One aspect of computer security involves protecting computer systems from malicious software, also known as “malware.” Malware comes in many forms; however, many common varieties of malware perform writes or other accesses to unauthorized locations in computer memory. For example, certain malware attacks low-level system code (e.g., platform initialization firmware, boot loaders, operating system kernels, etc.) during initial stages of the booting process. Such attacks may be used by so-called “bootkits” or “rootkits” to gain control of a system and evade detection.
Typical computer systems attempt to detect and prevent execution of malware by performing a “secure boot” or “secure launch.” To do so, computing systems may include a security engine or security coprocessor configured to verify the integrity of low-level system code prior to being loaded during the booting process. For example, upon initialization of the booting process, the security engine of a computing system may generate a hash of the firmware needed for initializing the main processor of the computing system. Subsequently, the security engine may compare that hash to a known good hash or checksum value corresponding to an unadulterated version of the firmware. If the two hashes are determined to be a match, the firmware may be permitted to be executed causing the main processor or other components of the computing system to be initialized.
Embedded and system-on-a-chip (SoC) systems are becoming more prevalent in the computing ecosystem. In typical SoC systems, the secure boot process is managed by an integrated security engine or security coprocessor having its own static random-access memory (SRAM) embedded in the SoC. To ensure a secure boot from the ground up, low-level system code must be verified by the integrated security engine prior to being permitted to be executed. Typically, such low-level system code must first be stored in the SRAM of the integrated security engine. Accordingly, the size of any low-level system code that is to be verified by the integrated security engine is effectively limited by the size of SRAM embedded into the SoC. In addition, increasing the total size of the SRAM on the SoC to enable the verification of larger-sized low-level system code is typically impractical due to the associated cost, die size, and power consumption of additional SRAM banks on the SoC.